It’s intended to define how digiplex compliant nodes will announce their presence, how the network and routing quality will be meassured and how the resulting information will be propagated across the network.

This is a protocol designed to allow the concurrent usage of it on existing radio networks which could operate without interference other L2/L3/L4 protocols concurrently such as L2 digipeaters, FlexNet, TCP/IP or NET/ROM nodes) making the details of the protocol both compatible with the AX.25 protocol specificacion and transparent to their operation.

The protocol has not been designed to be interoperable with other existing L3 protocols such as NET/ROM or FlexNet, either because it aims to overcome some shortcoming (NET/ROM) or because there is no published information to work with (FlexNet).

Still, the design criteria has been to carefully avoid conflict with them, so nodes supporting the different protocols could operate on the same radio channels, and to a point allow future extensions to introduce some degree of limited interoperability.

The initial implementation of the protocol is been made using the AGW Packet Engine by George Rossopoulos (SV2AGW) as the enabling platform; other platforms could adopt the basic set and implement it achieving interoperability as it seems it fit.

What is this Protocol for? Audience.

The main audience of this protocol are application programmers willing to support a common interchange protocol that enables digiplex compliant nodes to exchange information, it could also serve to the curious network node operator to understand the protocol, some of the configuration issues and for debugging purposes.

Protocol Description

The protocol aims to fulfill four basic needs

· Layer 3 (L3)

o Allow digiplex compliant resources to announce it presence on a given radio channel or set of radio channels.

o Enable digiplex compliant resources to meassure the quality of their interlink in order to gather basic routing information and to adapt to changing conditions on the radio channel.

o Define a way for digiplex compliant nodes to interchange and propagate routing information across the network.

· Layer 4 (L4)

o Establish the way on how information will be carried across the network.

Overview

The aim of any routing protocol is to define a way to select as automatically as possible the best route between two given geographical points over an available set of radio channels and upon the selection to carry information between those two points on a reliable way.

Network topologies and efficient routing algorithms are next to a science and there are very well developed protocols to fulfill that need already developed, specially as part of the TCP/IP suite of protocols.

However, amateur radio introduces some factors that are not very common to other environments which in most cases makes otherwise excellent network protocols to fail, among others the factors are:

· Amateur radio links aren’t necessarily reliable, either propagation conditions or other situations could make a given routing asset temporarily unavailable or to become unreliable or to increase significantly it’s response time. On top of that amateur links might not be implemented with S/N ratios margins like the commonly used on civil and military networks.

· Amateur nodes aren’t necessarily aiming to provide a full 7 x 24 Hours reliability, so critical routing resources might become temporarily or permanently unavailable at any time or even be available on a partial time basis.

· Amateur radio channels usually operates on low bandwidth scenarios, typical shared channels on the air baud rates are 1200/2400 for user channels and 9600 for internode/forward channels. Quite a limited number of networks operates at speed above that and even though bandwidth above 56 Kbps are extremely rare. Effective bandwidth could be considerably lower based on the total number of concurrent users a given radio channel has.

In order to cope with the above distinctive needs proprietary protocols needs to be developed.

Still, when for some reason one or more of the above restrictions doesn’t apply it is best to consider to establish routing protocols which has wider industry support, such as TCP/IP.

Other Routing Protocols Available

The most reasonable question anybody should ask is…. why yet another protocol?

That question could only be answered with a brief description of the main advantages and disadvantages of main existing protocols.

NET/ROM

A protocol originally developed in USA with important implementations from Germany and UK which had propagated at the World Wide scale.

Probably one of the most diseminated and most widely supported amateur L3/L4 protocol available, available mostly as a specialized controller and implemented on the DOS, Windows 16 bits and Linux platforms.

Supported by implementations in a very limited way on the Windows 32 bits platform.

Widely implemented across the world thru the G8BPQ switch package, a wide range of applications supports it.

NET/ROM uses a combination of UI frames to broadcast the existence of each node and its routing information with connected AX.25 sessions to actually route frames and transport information (L3/L4 layers).

The available routes are computed mostly based on actual activity between nodes and the content of the broadcasted information.

Routes become obsolete when expired (become obsolete) mostly thru the lack of a “refresh” information from the neighboor nodes.

Actual routing is made based on non-obsolete routes plus a “quality factor” defined by the sysop.

Main advantages:

Widely implemented and supported.
Strong, reliable and strengthed by the huge use at a global scale.
Relatively efficient in terms of bandwidth.

Main disadvantages:

Normal terminal programs doesn’t support it, an intermediate connection to a compliant node is required.
Overhead, part of the available space on the AX.25 frame is dedicated to held L3 and L4 headers.
Double link control, link sequences are maintained both at the L2 and L4 layers which often leads to additional traffic to be generated with no direct benefit in terms of accurancy of the information.
Slow network adaptation, information about nodes that becomes unavailable propagates slowly thru the network leading to broken routes still held active for routing purposes quite after it’s not longer usable.
Sometimes arbitrary routing based more on the sysop static configuration rather than actual network throughput.
Implementation for newer platforms are slow to appear forcing the amateur infrastructure to be run on obsolete platforms such as DOS.
Poorly documented, both at the protocol level and at the applications that implements it.

Still the best among the best, no new routing protocol would get thru if doesn’t allow even some limited interoperability with NET/ROM as reality showed time after time.

Rose

A transport protocol developed in the US and still mostly used there, it has limited implementation on dedicated switches, it’s usage is very limited althrough properly implemented networks are known to be very reliable.

Main advantages:

Run on specialized hardware.
Strong, reliable and strengthed by the huge use.
Relatively efficient in terms of bandwidth.

Main disadvantages:

Difficult to implement.
Routing scheme mostly static, reacts poorly to changing network conditions.
Sometimes arbitrary routing based more on the sysop static configuration rather than actual network throughput.
Implementation for newer platforms is nowhere in sight forcing the amateur infrastructure to be run on obsolete hardware platforms.
Poorly documented, both at the protocol level and at the applications that implements it.

FlexNet

Novel routing scheme developed originally in Germany and widely implemented on European networks.

Known implementations includes proprietary hardware, DOS and a limited porting into Windows 32 bits (user functions).

Flexnet uses a routing scheme based on the concept of an AX.25 L2 digipeater where the successive repeaters are selected based on the best path each node could find within the Flexnet network, each digipeater implements a very efficient hop-to-hop mechanism that avoids most of the pitfalls of a simple (dumb) Layer 2 digipeater.

Flexnet nodes interchange information among them for both made network changes be propagated to all participant nodes quite fast and to manage the actual circuits being carried thru the network.

Main advantages:

Widely implemented on Europe.
Strong, reliable and strengthed by the huge use.
Very flexible, highly adaptable to conditions and efficient routing scheme.
Relatively efficient in terms of bandwidth.

Main disadvantages:

Not an open standard, the very internode protocol is still (almost a decade after it’s introduction) undocummented, almost impossible to develop interoperability with it.
Limited platform implementations, for the infrastructure components essentially limited to proprietary hardware and DOS.
Very poor application side API documentation, it strongly discouraged the development of third authors applications; all Flexnet code seems to be doomed to either be created by it’s authors or not to exists at all.
Bizarre drivers strategy, most common TNCs requires modification to work with it in a supported way.

TCP/IP

Little or nothing could be told about TCP/IP that hasn’t already been told to exhaustion; it’s a moot point to try to list the advantages and disadvantages; compared with other amateur protocols it’s either going to be an empty list or a rather long list depending on the writer’s point of view.

But, in a nutshell, TCP/IP has been slow to be introduced on amateur networks, there are quite a few reasons for that.

It is more taxing in terms of bandwidth or directly not efficient compared with other proprietary (developed for the job) amateur protocols.
Amateur implementations relies mostly on static routing which adapts poorly to network changes in configuration and propagation conditions.

Niche for Yet another Protocol

Based on the previous compared list there is a place for a protocol that address the main constraints of the amateur needs, of an open nature and which a fair integration and interoperatibility with other major existing protocols which at the same time could be run on modern platforms allowing the upgrade of the infrastructure and the usage of newly available hardware.

Network Information

The network is assumed to be composed by a combination of available routing resources, whenever possible routes will be selected thru a sequence of digiplex compliant nodes but to a limited extent other resources such as FlexNet nodes, NET/ROM nodes and Layer 2 digipeaters could be used.

The total time to reach a destination (TT) is the average total time required for a frame to traverse a given route thru all the intermediate nodes involved.

It is composed by two factors, the time to reach the next neighboor (SNTT) which is obtained thru meassurement at each node and the time to traverse the remaining of the route (RT) which is obtained thru network information propagated between nodes.

Total time would then be TT = SNTT + RT at any moment.

The network could improve (positive information) either thru the improvement of the link of a given node to it’s neighboors (SNTT improvement) or some improvement at other parts of the route (RT improvement).

Likewise the network could deteriorate (negative information) because either the link of the node with it’s neighboors deteriorate (SNTT increase) or because at some other part of the path the response time increases (RT increase).

Each node would see the network based on those two factors, so the routing is made thru a cooperative combination of the information collected at the node by itself and the information provided by it’s neighboors.

Even with hop to hop acknowledgement any given route is better than other when the number of hops on that particular route is minimum, so a routing horizon of a maximum

of 8 hops is applied.

A given route would be despicted as unusable when:

A node participating in it is no longer reachable.
The Total Time (TT) growths above 600 secs.
The total number of hops required is at or above 8.

The Layer 3 component of the digiplex protocol is just one possible set of conventions for a node to obtain information related to the SNTT/RT and Hops to a give destination.

Digiplex Protocol

The digiplex protocol is based on the following major components.

A way to broadcast the existence of a node in the network (XDIGI frame).
A way to interact with both NET/ROM and FlexNet protocols (XPOLL frame).
A way to exchange network conditions between nodes and to propagate routing information (connected sessions between nodes, L3RTT headers and RIF info).
A way to compute the best route on a given moment.
A way to transport information across the routes (hop to hop ack).

The above components will be described in greater detail at the following sections.

XDIGI Frame

The XDIGI frame is the primary and preferred way for a node to make it’s presence known to the network and thus it’s implementation is mandatory.

At predefined and configurable times each node propagates a single UI frame from the callsign of the sender node with “XDIGI-0” as a destination with the following format on the information field:

Field	Length	Content
RIF	Variable	RIF information of the sender node.

The frame has to be broadcasted thru every radio port where the node supports digiplex routing using the callsign-SSID of the listener of that port (assuming different ports will have different callsigns-SSID defined).

The frame has to be repeated periodically.

XPOLL Frame

XPOLL frames are generated to query non-digiplex compliant nodes for availability, this frame is specially suited to validate the connectivity with Layer 2 digipeaters, NET/ROM nodes and FlexNet nodes; it’s implementation is optional.

Once sent thru the radio channel the node could watch the same frame being “repeated” over the air and thus extract conclusions (the other node hear us and how long it took the frame to be digipeated, the RTT).

At predefined and configurable times each node propagates a single UI frame from the callsign of the sender node with “XPOLL-0” as a destination and the node or resource which is required to be tested as the VIA path of the frame with the following format on the information field:

Field	Length	Content
RIF	Variable	RIF information of the sender node.

The frame has to be repeated periodically.

RTT Meassurement and Routing Info Exchange

For all digiplex resources detected by a given node an attempt of connection will be made periodically.

Upon connection the following events will occur:

The connecting node will send a L3RTT type frame, followed by the RIF information of all best routes to known nodes it has.
The connected node will bounce the L3RTT type frame received from the other side as received and process the RIF information received to update it’s own routing information; following that it will generate it’s own L3RTT type frame and send all it’s best routing information thru the corresponding RIF records of them.
The connecting node will bounce the L3RTT type frame received.
Both ends will disconnect.

Upon connection between nodes both will reset the connection cycle for a connection not to occur on the reverse path shortly thereafter.

L3RTT Header

The L3RTT frame has the purpose of meassure the turnaround of a given piece of information and thus meassure the RTT of the link (each side got an independent meassure of it).

The L3RTT frame is a regular I frame from the sending node to the connected node, with a PID=0xCF and the following content on the information field:

Field	Length	Content
Sender CallSign-SSID	7	Sender CallSign-SSID in AX.25 shifted format
Destination “L3RTT-0”	7	Fixed destination callsign and SSID in AX.25 shifted format.
Time To Live	1	Not used
Record Type	1	0x05
Header	4	filled with 0x00
Timming Info	Variable	Information used by the sender to compute the turnaround time when bounced back. dd/mm/yy hh:mm:ss am/pm as a plain ASCII string without any delimiter.
End of Record	1	0x10

Please note that the timming info is recommended but not enforced, each implementation could use whatever it seems fit for the purpose of computing the turn-around time (RTT) of the frame; the receiver of the frame should retransmit it back transparently.

RIF Header

The RIF header will contain information about a particular node thru the usage of a fixed part and a variable part (called RIP).

Field	Length	Content
Header Marker	1	0xFF
Node	7	Node CallSign and SSID in AX.25 shifted format
Hops	1	Total number of hops to reach the node from the sender thru the best route.
Network Time	2	Total time to reach the node thru the best route till the sender node, MSB first.
RIP	Variable	One or more RIP records

The RIP records will have the following format:

Field	Length	Content
RIP Length	1	Bytes of the information part of the RIP
RIP Type	1	Type of information stated
RIP Info	Variable	Information stated, variable length according with the first field

Supported RIP Types are:

Field	Type	Content
Node Alias	0x00	Alias of the Node, 6 bytes, no spaces
Digiplex Control Byte	0x02	Digiplex Control Byte where the properties of the node are stated.

Those are the minimum RIP information that must be transmitted, other RIP information could also be used. All implementation must manage to keep and retransmit any unrecognized (unsupported) RIP type as long as it complies with the basic RIP format.

As per version 1.0 of the protocol only one RIF record per physical AX.25 frame is allowed; none, one or more RIP records are supported per RIF as long as they fit on a single physical AX.25 frame.

As per version 1.0 of the protocol no RIF segmentation is allowed, still implementations should be prepared to handle more than one RIF per physical AX.25 frame as long as all them fits on a single frame.

Digiplex Control Byte

This byte will capture the relevant properties of a given protocol for the purpose of this protocol with the following structure:

Bit	Meaning	Content
7	Digiplex	Node is Digiplex
6	NET/ROM	Node is NET/ROM
5	FlexNet	Node is FlexNet
4	TCP/IP Worm	Node accessed thru L2 Worm TCP/IP
3	Layer 2 Digipeater	Node is L2 Digipeater
2	Heard Me	Node heard this node
1	Locked	Node info is locked
0	InterNode Established	Internode link established

Routing Algorithm

The routing algorithm is composed by the following steps:

Detect whether the routing has to be applied.
Select a particular route for the frame.
Apply routing decissions to frames.
Interoperability with other network protocols.

Routing Applicability

In order for the routing to be applicable and the node to operate in armony with other infrastructure resources present on the network which are not aware of the particulars of the digiplex protocol the following conditions has to be met:

The AX.25 frame over which a routing decision has to be taken has to have the router (listener) callsign indicated in it’s VIA path and it has to be the first callsign-SSID on the frame sequence which has the “Been Digied” bit in OFF (current digipeater).
The router has to be enabled.
A valid listener has to be enabled on the radio channel where the frame has been heard.

All frames that doesn’t meet the routing applicability will be ignored by the routing algorithm.

Best Route Selection

A route to a given destination will exists whenever there is information about the destination either directly gathered by the node or thru routes exchanges with a neighboor node.

Among the available routes, the best route to be selected is the one with according with the information of the node has less turnaround time.

This is the route for which SNTT+RT is the lowest, below the maximum routing TT (600 Secs) and within the routing horizon (8 hops or less).

Routing

The following criteria has to be used once the frame has been detected as applicable for routing.

There has to be at least one digipeater more in the VIA path after our callsign and it has to have the “Been Digied” bit in OFF signaling that it’s the next digi to be required to digipeat the frame. The routing actions will select if that digipeater could be reach by the node handling the frame or an intermediate route has to be selected instead.
If the node does not have a route to the next digipeater the frame is retransmited as in any Layer 2 digipeater, the current digipeater is marked with the “had been digied” bit in ON.
If the node does have a route to the next digipeater the following actions are applied:

If the next digipeater is identified as a digiplex compliant node and the best route to it is itself the frame is aired as in the case of a Layer 2 digipeater.
If the next digipeater is identified as either a digiplex compliant node or a Layer 2 digipeater but the best route to it is thru another node then the best route is added as next on the VIA path, the current node is marked with the “has been digied” bit in ON for the current node and the frame is aired.

Inteoperability with other Network Protocols

To define the exact means of interoperability with other network protocols is beyond the scope of this protocol description, each node implementation has to decide whether or not interoperability is supported or not and using which mechanisms.

The attributes of the different resources still need to be preserved and propagated despite the support for a particular interoperability feature.

Version Information

Version 1.0 (Preliminary)

Initial protocol description.

Disclaimer and License Statement

This protocol has been devised to promote experimentation on amateur radio digital modes, as such it is considered to be placed in the public domain.

Publicly available information has been used to understand the requirements, specially the AGWPE TCPIP Interface (AGWSockInterface.DOC by G.Rossopoulos SV2AGW) and the “AX.25 Amateur Packet Radio Link Layer Protocol” (AX25.DOC), the famous Appendix F of the TNN manual (for the NET/ROM protocol description) and specially the work “A New Routing Specification for Packet Radio Datagram Networks” by Andreas Gal (DB7KG) whose concepts are the core of the INP protocol here despicted.

All code used to implement this program remains under the ownership of the respective authors.

AX.25: LU7DID@LU7DID.#ADR.BA.ARG.SOAM

Inet: colla@pec.pccp.com.ar